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REMARKS/ARGUMENTS 
Claims 1, % 4-10 and 12-19 arc now pending in the present application. Claims 1, 2, 5-7. 9, 10, 
13-15, 17 and IS have been amended, and Claims 3 and 11 have been cancelled, herewith. 
Reconsideration of the pending claims is respectfully requested. 

1, » ILS.d g 103, Obviousness 

The Examiner rejected Claims 1-19 under 35 US.C. § 103 as being unpatentable over Scott et al. 
[US Patent Application No. 2002/0049760], in view of Outten et al. [US Patent No, 7,024,466], This 
rejecti on is respectful ly traversed . 

Applicants have amended Claim 1 to include the features previously recited in originally filed 
□aims 2 and 3 (which are thus being cancelled herewith without prejudice or disclaimer). As amended, 
Claim 1 recites steps of "dividing an electronic file into a plurality of file pieces" and "downloading all of 
said file pieces to a plurality of client machines, wherein the client machines function as peer-to-peer 
servers for other client machines requesting said file pieces, wherein each peer-to-peer server stores a 
unique file piece of the plurality of file pieces which is not stored on other of the peer-to-peer servers'*. 
As can be seen, an electronic file is divided into a plurality of file pieces, and all of these file pieces are 
downloaded to a plurality of client machines which function as peer-to-peer servers, where each pecr-to- 
peer server stores a unique file piece which is not stored on other of the peer-to-peer servers. These 
claimed features advantageously provide for scattering or seeding of file pieces across a peer-to-peer 
environment such that the file pieces can be more efficiently processed by eliminating potential network 
bottlenecks (Specification page 10, lines 1-22). In rejecting Claim 1, the Examiner states that the cited 
Scott reference teaches the claimed 'dividing* step at paragraphs 0055 and 0066 in that Scott describes 
file chunks. Applicants urge that Scott does not teach that a file is divided and downloaded as chunks to 
different servers, but rather that an entire file is downloaded to multiple clients, where these entire 
duplicate copies of the entire file can then be accessed to read individual chunks (paragraphs 0044, 0047 
and 0058), Importantly, Scott requires that duplicate copies of the entire file be maintained at each of the 
client devices, as the files are located using a hashing scheme in which the entire file is hashed to obtain a 
hash ID value. For example, as described by Scott at paragraph 005 1: 

It is crucial that the file contents on the first fulfilling Peer! (506) and the second 
fulfilling Peer3 (508) corresponding to HASH ID be identical in every respect, since 
otherwise these parts of files may not fit together correctly and result in a damaged or 
comipted final file, This is why it is essential to pick a HASH function that will uniquely 
create a unique HASH code from a file's contents. 
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It is therefore urged that the amendment to Claim 1 clearly differentiates the claimed dividing of an 
electronic file into a plurality of file pieces from Scott's description of maintaining entire copies of files at 
multiple client devices - albeit which can then be accessed as chunks when reading the file- 
In rejecting Claim 3 (whose features are now a part of amended Claim 1)> the Examiner states 
that Scott teaches that each peer-to-peer server stores a unique file piece at Scott Figures 2 and 4a; and 
paragraph 0008, in that Scott describes a hash ID, Applicants respectfully submit that a hash ID is not the 
result of dividing a file into a plurality of file pieces, and these resulting file pieces are uniquely stored on 
the peer-to-peer servers. Rather, the hash ID is the result of a calculation being performed on an entire 
file (Scott paragraph 0026). Thus, it is urged that the Examiner failed to establish a prima facie showing 
of obviousness with respect to Claim 3, and since such features are now a part of amended Claim 1. it is 
urged that Claim 1 is not obvious in view of the cited references as there are claimed features not taught 
or suggested by any of the cited references. 

Still further with respect to Claim 1 , such claim recites a conditional redirection of a request for a 
file piece. In rejecting such conditional redirection, the Examiner cites Outten' s teaching at column 6, 
lines 20-27 as teaching such claimed feature. Applicants urge that this passage cites an unconditional 
redirection with respect to an entire file. This is different than the features of Claim 1 for at least two 
reasons. First* the Outten redirection is with respect to accessing an entire file, whereas Claim 1 is 
directed to redirecting requests for file pieces (i.e. individual portions of an entire file, as per Claim 1). 
This distinction is critical when viewed in the context of a high performance peer-to-peer network as per 
the present invention, where reducing the size of units of information being transferred improves overall 
system performance by reducing bottlenecks (Specification page 9, line 29 - page 1 1, line 27). Therefore, 
Claim 1 is further shown to not be obvious in view of the cited references as there are additional claimed 
features not taught or suggested by the cited references. 

Secondly, this Outten redirection is unconditional, whereas the redirection of Claim 1 is condition 
(if said file piece requested from the second client machine has previously been downloaded to the first 
client machine responsive to the request for said file piece from the first client machine). Claim 2 has 
been amended to further emphasize this conditional/unconditional distinction. It is therefore further urged 
that amended Claim 2 is not obvious in view of the cited references - because of this conditional feature 
and because of Claim 2's dependency upon Claim 1 (which has been shown above to be unobvious in 
view of the cited references). 

Applicants initially traverse the rejection of CI aim & 4-6 for reasons given above with respect to 
Claim 2 (of which Claims 4-6 depend upon). 

Further with respect to Claim 3 (and dependent Claim 6). Applicants have amended such claim to 
clearly differentiate the claimed digest from Scott's description of a hash ID. As amended, Claim 5 
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recites that the digest is used to determine file piece corruption (as described in the Specification at page 
12, line 10 - page 13, line 24). The Scott hash ID is used to locate entire files, and thus is different from 
Claim 5 for at least two reasons. First, Scon's hash ID is with respect to an entire file, whereas the digest 
of Claim 5 is with respect to zfile piece resulting from a file being divided into pieces (as per Claim 1). 
This distinction is critical when viewed in the context of a high performance peer-to-peer network as per 
the present invention, where reducing the size of units of information being transferred improves overall 
system performance by reducing bottlenecks (Specification page 9, line 29 - page 11, line 27), Secondly, 
using a hash ID to locate a file, as per the teachings of the cited reference, is very different from 
determining file integrity (corruption) using a digest, as per Claim 5. It is thus urged that the amendment 
to Claim 5 clearly differentiates the features of Claim 5 from the teachings of the cited references, and 
therefore it is further urged that amended Claim 5 (and dependent Claim 6) is not obvious in view of the 
cited references. 

With respect to Claim 7, such claim is directed to redirecting of requests for individual file pieces, 
The redirection as provided by the cited Outten is with respect to entire files (Outten col. 6, lines 20-27). 
This distinction is critical when viewed in the context of a high performance peer-to-peer network as per 
the present invention, where reducing the size of units of information being transferred improves overall 
system performance by reducing bottlenecks (Specification page 9, line 29 - page 1 1 , line 27). In 
addition. Claim 7 has been amended to further differentiate the claimed features recited therein from the 
teachings of the cited references. Specifically, the redirection of requests to the first machine is 
conditioned upon whether the requested file piece has previously been provided to the first machine. In 
contrast, per the teachings of the cited Outten reference, the requests (for an entire file) are 
unconditionally redirected (as further articulated above with respect to Claims 1 and 2). Thus, it is further 
urged that Claim 7 is not obvious in view of the cited references as there at least two claimed features not 
taught or suggested by any of the cited references. 

With respect to Claim 8, such claim recites deceiving, by the first machine and without further 
request of the requested file piece by the first machine, the requested file piece from a second machine 
containing a copy of said file piece io Heu of receiving the requested file piece from the server, the copy 
of said ftte piece on the second machine being the result of a previous request for the file piece from the 
second machine to the server and receipt of the file piece from the server to the second machine". As can 
be seen, per the features of Claim 6, a first machine receives a file piece from a machine other than the 
one for which the request was directed (it is received from a second machine, whereas it was requested 
from a server), and the file piece that is received from the second machine is a copy of a file piece which 
was the result of a previous request for this same file piece. None of the cited references teach or suggest 
processing a request for a file piece differently - providing the file piece from a machine (the second 
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machine) other than the machine for which this request was directed (the server) - depending upon 
whether the file piece has previously been requested. In rejecting Claim &, the Examiner states that these 
features are taught by the passages cited in rejecting Claims 1 and 7. Applicants urge that Claim 8 is 
different from Claims 1 and 7, as described above, and mete reliance on the reasoning used in rejecting 
Claims 1 and 7 has not established a teaching or suggestion of the specific features recited in Claim 8 (as 
articulated above). Thus, a prima facie case of obviousness has not been established with respect to 
Claim 8, and therefore the burden has not shifted to Applicants to rebut such obviousness assertion 3 . In 
addition* as a proper prima facie showing of obviousness has not been established with respect to Claim 
8 ( such claim has been erroneously rejected 7 , 

Applicants traverse the rejection of Claims 9-14 for similar reasons to those given above with 
respect to Claim 1. 

Applicants further traverse the rejection of Claims 10 and 12-14 for similar reasons to the further 
reasons given above with respect to Claim 2. 

Applicants further traverse the rejection of Claims 13 and 14 for similar reasons to the further 
reasons given above with respect to Claim 5. 

Applicants traverse the rejection of Claim 15 for similar reasons to those given above with 
respect to Claim 7. 

Applicants traverse the rejection of Claim 16 for similar reasons to those given above with 
respect to Claim 8. 

Applicants traverse the rejection of Claim 17 for similar reasons to those given above with 
respect to Claim 1. 

Applicants traverse the rejection of Claim 18 for similar reasons to those given above with 
respect to Claim 7. 

Applicants traverse the rejection of Claim 19 for similar reasons to those given above with 
respect to Claim 8. 

Therefore* the rejection of Claims 1-19 under 35 U.S.C. § 103 has been overcome. 



x In rejecting claims under 35 U,S,C. Section 103. the examiner bears the initial burden of presenting a 
prima facie case of obviousness. In re Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443. 1444 (Fed. Cir. 
1992), Only if that burden is met, does the burden of coming forward with evidence or argument shift to 
the applicant. Id, To establish prima facie obviousness of a claimed invention, all of the claim limitations 
must be taught or suggested by the prior art MPEP 2143.03. See also, In re Royka, 490 F.2d 580 
(C.C.RA. 1974). 

2 If the examiner fails to establish a prima facie case, the rejection is improper and will be overturned. In 
re Fine, 637 F,2d 1071, 1074. 5 USFQ2d 1596, 1598 (Fed, Cir. 1988). 
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IL Conclusion 

It is respectfully urged that the subject application u patentable over the cited references and is 
now in condition for allowance. The Examiner is invited to call the undersigned at the below-listed 
telephone number if in the opinion of the Examiner such a telephone conference would expedite or aid the 
prosecution and examination of this application. 

DATE: July 7. 2006 



Respectfully submitted, 




Brian D. Owens 
Reg. No. 55,517 
Wayne P. Bailey 
Reg, No. 34,289 
Yee & Associates, RC. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Attorneys foT Applicants 
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